<!DOCTYPE html>
<html lang="en-us">
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    
<meta charset="UTF-8">
<title>Removal of mapping types | Elasticsearch Guide [7.7] | Elastic</title>
<link rel="home" href="index.html" title="Elasticsearch Guide [7.7]">
<link rel="up" href="mapping.html" title="Mapping">
<link rel="prev" href="mapping.html" title="Mapping">
<link rel="next" href="mapping-types.html" title="Field datatypes">
<meta name="DC.type" content="Learn/Docs/Elasticsearch/Reference/7.7">
<meta name="DC.subject" content="Elasticsearch">
<meta name="DC.identifier" content="7.7">
<meta name="robots" content="noindex,nofollow">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <script src="https://cdn.optimizely.com/js/18132920325.js"></script>
    <link rel="apple-touch-icon" sizes="57x57" href="/apple-icon-57x57.png">
    <link rel="apple-touch-icon" sizes="60x60" href="/apple-icon-60x60.png">
    <link rel="apple-touch-icon" sizes="72x72" href="/apple-icon-72x72.png">
    <link rel="apple-touch-icon" sizes="76x76" href="/apple-icon-76x76.png">
    <link rel="apple-touch-icon" sizes="114x114" href="/apple-icon-114x114.png">
    <link rel="apple-touch-icon" sizes="120x120" href="/apple-icon-120x120.png">
    <link rel="apple-touch-icon" sizes="144x144" href="/apple-icon-144x144.png">
    <link rel="apple-touch-icon" sizes="152x152" href="/apple-icon-152x152.png">
    <link rel="apple-touch-icon" sizes="180x180" href="/apple-icon-180x180.png">
    <link rel="icon" type="image/png" href="/favicon-32x32.png" sizes="32x32">
    <link rel="icon" type="image/png" href="/android-chrome-192x192.png" sizes="192x192">
    <link rel="icon" type="image/png" href="/favicon-96x96.png" sizes="96x96">
    <link rel="icon" type="image/png" href="/favicon-16x16.png" sizes="16x16">
    <link rel="manifest" href="/manifest.json">
    <meta name="apple-mobile-web-app-title" content="Elastic">
    <meta name="application-name" content="Elastic">
    <meta name="msapplication-TileColor" content="#ffffff">
    <meta name="msapplication-TileImage" content="/mstile-144x144.png">
    <meta name="theme-color" content="#ffffff">
    <meta name="naver-site-verification" content="936882c1853b701b3cef3721758d80535413dbfd">
    <meta name="yandex-verification" content="d8a47e95d0972434">
    <meta name="localized" content="true">
    <meta name="st:robots" content="follow,index">
    <meta property="og:image" content="https://www.elastic.co/static/images/elastic-logo-200.png">
    <link rel="shortcut icon" href="/favicon.ico" type="image/x-icon">
    <link rel="icon" href="/favicon.ico" type="image/x-icon">
    <link rel="apple-touch-icon-precomposed" sizes="64x64" href="/favicon_64x64_16bit.png">
    <link rel="apple-touch-icon-precomposed" sizes="32x32" href="/favicon_32x32.png">
    <link rel="apple-touch-icon-precomposed" sizes="16x16" href="/favicon_16x16.png">
    <!-- Give IE8 a fighting chance -->
    <!--[if lt IE 9]>
    <script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
    <script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
    <![endif]-->
    <link rel="stylesheet" type="text/css" href="/guide/static/styles.css">
  </head>

  <!--© 2015-2021 Elasticsearch B.V. Copying, publishing and/or distributing without written permission is strictly prohibited.-->

  <body>
    <!-- Google Tag Manager -->
    <script>dataLayer = [];</script><noscript><iframe src="//www.googletagmanager.com/ns.html?id=GTM-58RLH5" height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
    <script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= '//www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-58RLH5');</script>
    <!-- End Google Tag Manager -->

    <!-- Global site tag (gtag.js) - Google Analytics -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=UA-12395217-16"></script>
    <script>
      window.dataLayer = window.dataLayer || [];
      function gtag(){dataLayer.push(arguments);}
      gtag('js', new Date());
      gtag('config', 'UA-12395217-16');
    </script>

    <!--BEGIN QUALTRICS WEBSITE FEEDBACK SNIPPET-->
    <script type="text/javascript">
      (function(){var g=function(e,h,f,g){
      this.get=function(a){for(var a=a+"=",c=document.cookie.split(";"),b=0,e=c.length;b<e;b++){for(var d=c[b];" "==d.charAt(0);)d=d.substring(1,d.length);if(0==d.indexOf(a))return d.substring(a.length,d.length)}return null};
      this.set=function(a,c){var b="",b=new Date;b.setTime(b.getTime()+6048E5);b="; expires="+b.toGMTString();document.cookie=a+"="+c+b+"; path=/; "};
      this.check=function(){var a=this.get(f);if(a)a=a.split(":");else if(100!=e)"v"==h&&(e=Math.random()>=e/100?0:100),a=[h,e,0],this.set(f,a.join(":"));else return!0;var c=a[1];if(100==c)return!0;switch(a[0]){case "v":return!1;case "r":return c=a[2]%Math.floor(100/c),a[2]++,this.set(f,a.join(":")),!c}return!0};
      this.go=function(){if(this.check()){var a=document.createElement("script");a.type="text/javascript";a.src=g;document.body&&document.body.appendChild(a)}};
      this.start=function(){var a=this;window.addEventListener?window.addEventListener("load",function(){a.go()},!1):window.attachEvent&&window.attachEvent("onload",function(){a.go()})}};
      try{(new g(100,"r","QSI_S_ZN_emkP0oSe9Qrn7kF","https://znemkp0ose9qrn7kf-elastic.siteintercept.qualtrics.com/WRSiteInterceptEngine/?Q_ZID=ZN_emkP0oSe9Qrn7kF")).start()}catch(i){}})();
    </script><div id="ZN_emkP0oSe9Qrn7kF"><!--DO NOT REMOVE-CONTENTS PLACED HERE--></div>
    <!--END WEBSITE FEEDBACK SNIPPET-->

    <div id="elastic-nav" style="display:none;"></div>
    <script src="https://www.elastic.co/elastic-nav.js"></script>

    <!-- Subnav -->
    <div>
      <div>
        <div class="tertiary-nav d-none d-md-block">
          <div class="container">
            <div class="p-t-b-15 d-flex justify-content-between nav-container">
              <div class="breadcrum-wrapper"><span><a href="/guide/" style="font-size: 14px; font-weight: 600; color: #000;">Docs</a></span></div>
            </div>
          </div>
        </div>
      </div>
    </div>

    <div class="main-container">
      <section id="content">
        <div class="content-wrapper">

          <section id="guide" lang="en">
            <div class="container">
              <div class="row">
                <div class="col-xs-12 col-sm-8 col-md-8 guide-section">
                  <!-- start body -->
                  <div class="page_header">
<strong>IMPORTANT</strong>: No additional bug fixes or documentation updates
will be released for this version. For the latest information, see the
<a href="../current/index.html">current release documentation</a>.
</div>
<div id="content">
<div class="breadcrumbs">
<span class="breadcrumb-link"><a href="index.html">Elasticsearch Guide [7.7]</a></span>
»
<span class="breadcrumb-link"><a href="mapping.html">Mapping</a></span>
»
<span class="breadcrumb-node">Removal of mapping types</span>
</div>
<div class="navheader">
<span class="prev">
<a href="mapping.html">« Mapping</a>
</span>
<span class="next">
<a href="mapping-types.html">Field datatypes »</a>
</span>
</div>
<div class="chapter">
<div class="titlepage"><div><div>
<h2 class="title">
<a id="removal-of-types"></a>Removal of mapping types<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h2>
</div></div></div>
<div class="important admon">
<div class="icon"></div>
<div class="admon_content">
<p>Indices created in Elasticsearch 7.0.0 or later no longer accept a
<code class="literal">_default_</code> mapping. Indices created in 6.x will continue to function as before
in Elasticsearch 6.x. Types are deprecated in APIs in 7.0, with breaking changes
to the index creation, put mapping, get mapping, put template, get template and
get field mappings APIs.</p>
</div>
</div>
<h3>
<a id="_what_are_mapping_types"></a>What are mapping types?<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h3>
<p>Since the first release of Elasticsearch, each document has been stored in a
single index and assigned a single mapping type.  A mapping type was used to
represent the type of document or entity being indexed, for instance a
<code class="literal">twitter</code> index might have a <code class="literal">user</code> type and a <code class="literal">tweet</code> type.</p>
<p>Each mapping type could have its own fields, so the <code class="literal">user</code> type might have a
<code class="literal">full_name</code> field, a <code class="literal">user_name</code> field, and an <code class="literal">email</code> field, while the
<code class="literal">tweet</code> type could have a <code class="literal">content</code> field, a <code class="literal">tweeted_at</code> field and, like the
<code class="literal">user</code> type, a <code class="literal">user_name</code> field.</p>
<p>Each document had a <code class="literal">_type</code> meta-field containing the type name, and searches
could be limited to one or more types by specifying the type name(s) in the
URL:</p>
<div class="pre_wrapper lang-js">
<pre class="programlisting prettyprint lang-js">GET twitter/user,tweet/_search
{
  "query": {
    "match": {
      "user_name": "kimchy"
    }
  }
}</pre>
</div>
<p>The <code class="literal">_type</code> field was combined with the document’s <code class="literal">_id</code> to generate a <code class="literal">_uid</code>
field, so documents of different types with the same <code class="literal">_id</code> could exist in a
single index.</p>
<p>Mapping types were also used to establish a
<a class="xref" href="parent-join.html" title="Join datatype">parent-child relationship</a>
between documents, so documents of type <code class="literal">question</code> could be parents to
documents of type <code class="literal">answer</code>.</p>
<h3>
<a id="_why_are_mapping_types_being_removed"></a>Why are mapping types being removed?<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h3>
<p>Initially, we spoke about an “index” being similar to a “database” in an
SQL database, and a “type” being equivalent to a
“table”.</p>
<p>This was a bad analogy that led to incorrect assumptions. In an SQL database,
tables are independent of each other.  The columns in one table have no
bearing on columns with the same name in another table.  This is not the case
for fields in a mapping type.</p>
<p>In an Elasticsearch index, fields that have the same name in different mapping
types are backed by the same Lucene field internally.  In other words, using
the example above, the <code class="literal">user_name</code> field in the <code class="literal">user</code> type is stored in
exactly the same field as the <code class="literal">user_name</code> field in the <code class="literal">tweet</code> type, and both
<code class="literal">user_name</code> fields must have the same mapping (definition) in both types.</p>
<p>This can lead to frustration when, for example, you want <code class="literal">deleted</code> to be a
<code class="literal">date</code> field in one type and a <code class="literal">boolean</code> field in another type in the same
index.</p>
<p>On top of that, storing different entities that have few or no fields in
common in the same index leads to sparse data and interferes with Lucene’s
ability to compress documents efficiently.</p>
<p>For these reasons, we have decided to remove the concept of mapping types from
Elasticsearch.</p>
<h3>
<a id="_alternatives_to_mapping_types"></a>Alternatives to mapping types<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h3>
<h4>
<a id="_index_per_document_type"></a>Index per document type<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h4>
<p>The first alternative is to have an index per document type.  Instead of
storing tweets and users in a single <code class="literal">twitter</code> index, you could store tweets
in the <code class="literal">tweets</code> index and users in the <code class="literal">user</code> index. Indices are completely
independent of each other and so there will be no conflict of field types
between indices.</p>
<p>This approach has two benefits:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
Data is more likely to be dense and so benefit from compression techniques
used in Lucene.
</li>
<li class="listitem">
The term statistics used for scoring in full text search are more likely to
be accurate because all documents in the same index represent a single
entity.
</li>
</ul>
</div>
<p>Each index can be sized appropriately for the number of documents it will
contain: you can use a smaller number of primary shards for <code class="literal">users</code> and a
larger number of primary shards for <code class="literal">tweets</code>.</p>
<h4>
<a id="_custom_type_field"></a>Custom type field<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h4>
<p>Of course, there is a limit to how many primary shards can exist in a cluster
so you may not want to waste an entire shard for a collection of only a few
thousand documents.  In this case, you can implement your own custom <code class="literal">type</code>
field which will work in a similar way to the old <code class="literal">_type</code>.</p>
<p>Let’s take the <code class="literal">user</code>/<code class="literal">tweet</code> example above.  Originally, the workflow would
have looked something like this:</p>
<div class="pre_wrapper lang-js">
<pre class="programlisting prettyprint lang-js">PUT twitter
{
  "mappings": {
    "user": {
      "properties": {
        "name": { "type": "text" },
        "user_name": { "type": "keyword" },
        "email": { "type": "keyword" }
      }
    },
    "tweet": {
      "properties": {
        "content": { "type": "text" },
        "user_name": { "type": "keyword" },
        "tweeted_at": { "type": "date" }
      }
    }
  }
}

PUT twitter/user/kimchy
{
  "name": "Shay Banon",
  "user_name": "kimchy",
  "email": "shay@kimchy.com"
}

PUT twitter/tweet/1
{
  "user_name": "kimchy",
  "tweeted_at": "2017-10-24T09:00:00Z",
  "content": "Types are going away"
}

GET twitter/tweet/_search
{
  "query": {
    "match": {
      "user_name": "kimchy"
    }
  }
}</pre>
</div>
<p>You can achieve the same thing by adding a custom <code class="literal">type</code> field as follows:</p>
<div class="pre_wrapper lang-js">
<pre class="programlisting prettyprint lang-js">PUT twitter
{
  "mappings": {
    "_doc": {
      "properties": {
        "type": { "type": "keyword" }, <a id="CO284-1"></a><i class="conum" data-value="1"></i>
        "name": { "type": "text" },
        "user_name": { "type": "keyword" },
        "email": { "type": "keyword" },
        "content": { "type": "text" },
        "tweeted_at": { "type": "date" }
      }
    }
  }
}

PUT twitter/_doc/user-kimchy
{
  "type": "user", <a id="CO284-2"></a><i class="conum" data-value="1"></i>
  "name": "Shay Banon",
  "user_name": "kimchy",
  "email": "shay@kimchy.com"
}

PUT twitter/_doc/tweet-1
{
  "type": "tweet", <a id="CO284-3"></a><i class="conum" data-value="1"></i>
  "user_name": "kimchy",
  "tweeted_at": "2017-10-24T09:00:00Z",
  "content": "Types are going away"
}

GET twitter/_search
{
  "query": {
    "bool": {
      "must": {
        "match": {
          "user_name": "kimchy"
        }
      },
      "filter": {
        "match": {
          "type": "tweet" <a id="CO284-4"></a><i class="conum" data-value="1"></i>
        }
      }
    }
  }
}</pre>
</div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO284-1"><i class="conum" data-value="1"></i></a><a href="#CO284-2"></a><a href="#CO284-3"></a><a href="#CO284-4"></a></p>
</td>
<td align="left" valign="top">
<p>The explicit <code class="literal">type</code> field takes the place of the implicit <code class="literal">_type</code> field.</p>
</td>
</tr>
</table>
</div>
<h4>
<a id="parent-child-mapping-types"></a>Parent/Child without mapping types<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h4>
<p>Previously, a parent-child relationship was represented by making one mapping
type the parent, and one or more other mapping types the children.  Without
types, we can no longer use this syntax.  The parent-child feature will
continue to function as before, except that the way of expressing the
relationship between documents has been changed to use the new
<a class="xref" href="parent-join.html" title="Join datatype"><code class="literal">join</code> field</a>.</p>
<h3>
<a id="_schedule_for_removal_of_mapping_types"></a>Schedule for removal of mapping types<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h3>
<p>This is a big change for our users, so we have tried to make it as painless as
possible.  The change will roll out as follows:</p>
<div class="variablelist">
<dl class="variablelist">
<dt>
<span class="term">
Elasticsearch 5.6.0
</span>
</dt>
<dd>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
Setting <code class="literal">index.mapping.single_type: true</code> on an index will enable the
single-type-per-index behaviour which will be enforced in 6.0.
</li>
<li class="listitem">
The <a class="xref" href="parent-join.html" title="Join datatype"><code class="literal">join</code> field</a> replacement for parent-child is available
on indices created in 5.6.
</li>
</ul>
</div>
</dd>
<dt>
<span class="term">
Elasticsearch 6.x
</span>
</dt>
<dd>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
Indices created in 5.x will continue to function in 6.x as they did in 5.x.
</li>
<li class="listitem">
Indices created in 6.x only allow a single-type per index.  Any name
can be used for the type, but there can be only one. The preferred type name
is <code class="literal">_doc</code>, so that index APIs have the same path as they will have in 7.0:
<code class="literal">PUT {index}/_doc/{id}</code> and <code class="literal">POST {index}/_doc</code>
</li>
<li class="listitem">
The <code class="literal">_type</code> name can no longer be combined with the <code class="literal">_id</code> to form the <code class="literal">_uid</code>
field. The <code class="literal">_uid</code> field has become an alias for the <code class="literal">_id</code> field.
</li>
<li class="listitem">
New indices no longer support the old-style of parent/child and should
use the <a class="xref" href="parent-join.html" title="Join datatype"><code class="literal">join</code> field</a> instead.
</li>
<li class="listitem">
The <code class="literal">_default_</code> mapping type is deprecated.
</li>
<li class="listitem">
In 6.8, the index creation, index template, and mapping APIs support a query
string parameter (<code class="literal">include_type_name</code>) which indicates whether requests and
responses should include a type name. It defaults to <code class="literal">true</code>, and should be set
to an explicit value to prepare to upgrade to 7.0. Not setting <code class="literal">include_type_name</code>
will result in a deprecation warning. Indices which don’t have an explicit type will
use the dummy type name <code class="literal">_doc</code>.
</li>
</ul>
</div>
</dd>
<dt>
<span class="term">
Elasticsearch 7.x
</span>
</dt>
<dd>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
Specifying types in requests is deprecated. For instance, indexing a
document no longer requires a document <code class="literal">type</code>.  The new index APIs
are <code class="literal">PUT {index}/_doc/{id}</code> in case of explicit ids and <code class="literal">POST {index}/_doc</code>
for auto-generated ids. Note that in 7.0, <code class="literal">_doc</code> is a permanent part of the
path, and represents the endpoint name rather than the document type.
</li>
<li class="listitem">
The <code class="literal">include_type_name</code> parameter in the index creation, index template,
and mapping APIs will default to <code class="literal">false</code>. Setting the parameter at all will
result in a deprecation warning.
</li>
<li class="listitem">
The <code class="literal">_default_</code> mapping type is removed.
</li>
</ul>
</div>
</dd>
<dt>
<span class="term">
Elasticsearch 8.x
</span>
</dt>
<dd>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
Specifying types in requests is no longer supported.
</li>
<li class="listitem">
The <code class="literal">include_type_name</code> parameter is removed.
</li>
</ul>
</div>
</dd>
</dl>
</div>
<h3>
<a id="_migrating_multi_type_indices_to_single_type"></a>Migrating multi-type indices to single-type<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h3>
<p>The <a class="xref" href="docs-reindex.html" title="Reindex API">Reindex API</a> can be used to convert multi-type indices to
single-type indices. The following examples can be used in Elasticsearch 5.6
or Elasticsearch 6.x.  In 6.x, there is no need to specify
<code class="literal">index.mapping.single_type</code> as that is the default.</p>
<h4>
<a id="_index_per_document_type_2"></a>Index per document type<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h4>
<p>This first example splits our <code class="literal">twitter</code> index into a <code class="literal">tweets</code> index and a
<code class="literal">users</code> index:</p>
<div class="pre_wrapper lang-js">
<pre class="programlisting prettyprint lang-js">PUT users
{
  "settings": {
    "index.mapping.single_type": true
  },
  "mappings": {
    "_doc": {
      "properties": {
        "name": {
          "type": "text"
        },
        "user_name": {
          "type": "keyword"
        },
        "email": {
          "type": "keyword"
        }
      }
    }
  }
}

PUT tweets
{
  "settings": {
    "index.mapping.single_type": true
  },
  "mappings": {
    "_doc": {
      "properties": {
        "content": {
          "type": "text"
        },
        "user_name": {
          "type": "keyword"
        },
        "tweeted_at": {
          "type": "date"
        }
      }
    }
  }
}

POST _reindex
{
  "source": {
    "index": "twitter",
    "type": "user"
  },
  "dest": {
    "index": "users",
    "type": "_doc"
  }
}

POST _reindex
{
  "source": {
    "index": "twitter",
    "type": "tweet"
  },
  "dest": {
    "index": "tweets",
    "type": "_doc"
  }
}</pre>
</div>
<h4>
<a id="_custom_type_field_2"></a>Custom type field<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h4>
<p>This next example adds a custom <code class="literal">type</code> field and sets it to the value of the
original <code class="literal">_type</code>.  It also adds the type to the <code class="literal">_id</code> in case there are any
documents of different types which have conflicting IDs:</p>
<div class="pre_wrapper lang-js">
<pre class="programlisting prettyprint lang-js">PUT new_twitter
{
  "mappings": {
    "_doc": {
      "properties": {
        "type": {
          "type": "keyword"
        },
        "name": {
          "type": "text"
        },
        "user_name": {
          "type": "keyword"
        },
        "email": {
          "type": "keyword"
        },
        "content": {
          "type": "text"
        },
        "tweeted_at": {
          "type": "date"
        }
      }
    }
  }
}


POST _reindex
{
  "source": {
    "index": "twitter"
  },
  "dest": {
    "index": "new_twitter"
  },
  "script": {
    "source": """
      ctx._source.type = ctx._type;
      ctx._id = ctx._type + '-' + ctx._id;
      ctx._type = '_doc';
    """
  }
}</pre>
</div>
<h3>
<a id="_typeless_apis_in_7_0"></a>Typeless APIs in 7.0<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h3>
<p>In Elasticsearch 7.0, each API will support typeless requests,
and specifying a type will produce a deprecation warning.</p>
<div class="note admon">
<div class="icon"></div>
<div class="admon_content">
<p>Typeless APIs work even if the target index contains a custom type.
For example, if an index has the custom type name <code class="literal">my_type</code>, we can add
documents to it using typeless <code class="literal">index</code> calls, and load documents with typeless
<code class="literal">get</code> calls.</p>
</div>
</div>
<h4>
<a id="_index_apis"></a>Index APIs<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h4>
<p>Index creation, index template, and mapping APIs support a new <code class="literal">include_type_name</code>
URL parameter that specifies whether mapping definitions in requests and responses
should contain the type name. The parameter defaults to <code class="literal">true</code> in version 6.8 to
match the pre-7.0 behavior of using type names in mappings. It defaults to <code class="literal">false</code>
in version 7.0 and will be removed in version 8.0.</p>
<p>It should be set explicitly in 6.8 to prepare to upgrade to 7.0. To avoid deprecation
warnings in 6.8, the parameter can be set to either <code class="literal">true</code> or <code class="literal">false</code>. In 7.0, setting
<code class="literal">include_type_name</code> at all will result in a deprecation warning.</p>
<p>See some examples of interactions with Elasticsearch with this option set to <code class="literal">false</code>:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">PUT index?include_type_name=false
{
  "mappings": {
    "properties": { <a id="CO285-1"></a><i class="conum" data-value="1"></i>
      "foo": {
        "type": "keyword"
      }
    }
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/607.console"></div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO285-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>Mappings are included directly under the <code class="literal">mappings</code> key, without a type name.</p>
</td>
</tr>
</table>
</div>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">PUT index/_mappings?include_type_name=false
{
  "properties": { <a id="CO286-1"></a><i class="conum" data-value="1"></i>
    "bar": {
      "type": "text"
    }
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/608.console"></div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO286-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>Mappings are included directly under the <code class="literal">mappings</code> key, without a type name.</p>
</td>
</tr>
</table>
</div>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">GET index/_mappings?include_type_name=false</pre>
</div>
<div class="console_widget" data-snippet="snippets/609.console"></div>
<p>The above call returns</p>
<div class="pre_wrapper lang-console-result">
<pre class="programlisting prettyprint lang-console-result">{
  "index": {
    "mappings": {
      "properties": { <a id="CO287-1"></a><i class="conum" data-value="1"></i>
        "foo": {
          "type": "keyword"
        },
        "bar": {
          "type": "text"
        }
      }
    }
  }
}</pre>
</div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO287-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>Mappings are included directly under the <code class="literal">mappings</code> key, without a type name.</p>
</td>
</tr>
</table>
</div>
<h4>
<a id="_document_apis"></a>Document APIs<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h4>
<p>In 7.0, index APIs must be called with the <code class="literal">{index}/_doc</code> path for automatic
generation of the <code class="literal">_id</code> and <code class="literal">{index}/_doc/{id}</code> with explicit ids.</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">PUT index/_doc/1
{
  "foo": "baz"
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/610.console"></div>
<div class="pre_wrapper lang-console-result">
<pre class="programlisting prettyprint lang-console-result">{
  "_index": "index",
  "_id": "1",
  "_type": "_doc",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 0,
  "_primary_term": 1
}</pre>
</div>
<p>Similarly, the <code class="literal">get</code> and <code class="literal">delete</code> APIs use the path <code class="literal">{index}/_doc/{id}</code>:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">GET index/_doc/1</pre>
</div>
<div class="console_widget" data-snippet="snippets/611.console"></div>
<div class="note admon">
<div class="icon"></div>
<div class="admon_content">
<p>In 7.0, <code class="literal">_doc</code> represents the endpoint name instead of the document type.
The <code class="literal">_doc</code> component is a permanent part of the path for the document <code class="literal">index</code>,
<code class="literal">get</code>, and <code class="literal">delete</code> APIs going forward, and will not be removed in 8.0.</p>
</div>
</div>
<p>For API paths that contain both a type and endpoint name like <code class="literal">_update</code>,
in 7.0 the endpoint will immediately follow the index name:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">POST index/_update/1
{
    "doc" : {
        "foo" : "qux"
    }
}

GET /index/_source/1</pre>
</div>
<div class="console_widget" data-snippet="snippets/612.console"></div>
<p>Types should also no longer appear in the body of requests. The following
example of bulk indexing omits the type both in the URL, and in the individual
bulk commands:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">POST _bulk
{ "index" : { "_index" : "index", "_id" : "3" } }
{ "foo" : "baz" }
{ "index" : { "_index" : "index", "_id" : "4" } }
{ "foo" : "qux" }</pre>
</div>
<div class="console_widget" data-snippet="snippets/613.console"></div>
<h4>
<a id="_search_apis"></a>Search APIs<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h4>
<p>When calling a search API such <code class="literal">_search</code>, <code class="literal">_msearch</code>, or <code class="literal">_explain</code>, types
should not be included in the URL. Additionally, the <code class="literal">_type</code> field should not
be used in queries, aggregations, or scripts.</p>
<h4>
<a id="_types_in_responses"></a>Types in responses<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h4>
<p>The document and search APIs will continue to return a <code class="literal">_type</code> key in
responses, to avoid breaks to response parsing. However, the key is
considered deprecated and should no longer be referenced. Types will
be completely removed from responses in 8.0.</p>
<p>Note that when a deprecated typed API is used, the index’s mapping type will be
returned as normal, but that typeless APIs will return the dummy type <code class="literal">_doc</code>
in the response. For example, the following typeless <code class="literal">get</code> call will always
return <code class="literal">_doc</code> as the type, even if the mapping has a custom type name like
<code class="literal">my_type</code>:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">PUT index/my_type/1
{
  "foo": "baz"
}

GET index/_doc/1</pre>
</div>
<div class="console_widget" data-snippet="snippets/614.console"></div>
<div class="pre_wrapper lang-console-result">
<pre class="programlisting prettyprint lang-console-result">{
    "_index" : "index",
    "_type" : "_doc",
    "_id" : "1",
    "_version" : 1,
    "_seq_no" : 0,
    "_primary_term" : 1,
    "found": true,
    "_source" : {
        "foo" : "baz"
    }
}</pre>
</div>
<h4>
<a id="_index_templates"></a>Index templates<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h4>
<p>It is recommended to make index templates typeless by re-adding them with
<code class="literal">include_type_name</code> set to <code class="literal">false</code>. Under the hood, typeless templates will use
the dummy type <code class="literal">_doc</code> when creating indices.</p>
<p>In case typeless templates are used with typed index creation calls or typed
templates are used with typeless index creation calls, the template will still
be applied but the index creation call decides whether there should be a type
or not. For instance in the below example, <code class="literal">index-1-01</code> will have a type in
spite of the fact that it matches a template that is typeless, and <code class="literal">index-2-01</code>
will be typeless in spite of the fact that it matches a template that defines
a type. Both <code class="literal">index-1-01</code> and <code class="literal">index-2-01</code> will inherit the <code class="literal">foo</code> field from
the template that they match.</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">PUT _template/template1
{
  "index_patterns":[ "index-1-*" ],
  "mappings": {
    "properties": {
      "foo": {
        "type": "keyword"
      }
    }
  }
}

PUT _template/template2?include_type_name=true
{
  "index_patterns":[ "index-2-*" ],
  "mappings": {
    "type": {
      "properties": {
        "foo": {
          "type": "keyword"
        }
      }
    }
  }
}

PUT index-1-01?include_type_name=true
{
  "mappings": {
    "type": {
      "properties": {
        "bar": {
          "type": "long"
        }
      }
    }
  }
}

PUT index-2-01
{
  "mappings": {
    "properties": {
      "bar": {
        "type": "long"
      }
    }
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/615.console"></div>
<p>In case of implicit index creation, because of documents that get indexed in
an index that doesn’t exist yet, the template is always honored. This is
usually not a problem due to the fact that typeless index calls work on typed
indices.</p>
<h4>
<a id="_mixed_version_clusters"></a>Mixed-version clusters<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/mapping/removal_of_types.asciidoc">edit</a>
</h4>
<p>In a cluster composed of both 6.8 and 7.0 nodes, the parameter
<code class="literal">include_type_name</code> should be specified in index APIs like index
creation. This is because the parameter has a different default between
6.8 and 7.0, so the same mapping definition will not be valid for both
node versions.</p>
<p>Typeless document APIs such as <code class="literal">bulk</code> and <code class="literal">update</code> are only available as of
7.0, and will not work with 6.8 nodes. This also holds true for the typeless
versions of queries that perform document lookups, such as <code class="literal">terms</code>.</p>
</div>
<div class="navfooter">
<span class="prev">
<a href="mapping.html">« Mapping</a>
</span>
<span class="next">
<a href="mapping-types.html">Field datatypes »</a>
</span>
</div>
</div>

                  <!-- end body -->
                </div>
                <div class="col-xs-12 col-sm-4 col-md-4" id="right_col">
                  <div id="rtpcontainer" style="display: block;">
                    <div class="mktg-promo">
                      <h3>Most Popular</h3>
                      <ul class="icons">
                        <li class="icon-elasticsearch-white"><a href="https://www.elastic.co/webinars/getting-started-elasticsearch?baymax=default&amp;elektra=docs&amp;storm=top-video">Get Started with Elasticsearch: Video</a></li>
                        <li class="icon-kibana-white"><a href="https://www.elastic.co/webinars/getting-started-kibana?baymax=default&amp;elektra=docs&amp;storm=top-video">Intro to Kibana: Video</a></li>
                        <li class="icon-logstash-white"><a href="https://www.elastic.co/webinars/introduction-elk-stack?baymax=default&amp;elektra=docs&amp;storm=top-video">ELK for Logs &amp; Metrics: Video</a></li>
                      </ul>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </section>

        </div>


<div id="elastic-footer"></div>
<script src="https://www.elastic.co/elastic-footer.js"></script>
<!-- Footer Section end-->

      </section>
    </div>

<script src="/guide/static/jquery.js"></script>
<script type="text/javascript" src="/guide/static/docs.js"></script>
<script type="text/javascript">
  window.initial_state = {}</script>
  </body>
</html>
